Skip to content

Add more workflow file linting with Zizmor#9767

Open
johnbillion wants to merge 22 commits intoWordPress:trunkfrom
johnbillion:workflow-linting
Open

Add more workflow file linting with Zizmor#9767
johnbillion wants to merge 22 commits intoWordPress:trunkfrom
johnbillion:workflow-linting

Conversation

@johnbillion
Copy link
Copy Markdown
Member

@johnbillion johnbillion commented Sep 5, 2025

Previously:

This change:

  • Introduces Zizmor which is a tool for linting workflow files for security weaknesses.
  • Fixes some issues in workflow files that were identified by Zizmor.

Code scanning alerts

Like the existing Actionlint job, Zizmor reports to GitHub Code Scanning by uploading a SARIF report via the github/codeql-action/upload-sarif action (none of these tools use CodeQL but GitHub groups its code scanning actions under the CodeQL name).

  • This makes the results available on the Security → Code Scanning screen for users with write permission on the repo.
  • Code scanning errors and warnings that are newly introduced in a PR will cause the code scanning to fail. The code scanning job itself won't fail, it will produce a separate "Code scanning results" workflow on the Checks screen which shows the failures, accompanied with an inline annotation on the affected file and line.
  • Existing issues (documented below) will remain in place until fixed or dismissed. They won't affect new PRs, so they behave like a baseline.
    • Note: It's unclear whether the dismissed issues in this branch will carry across to trunk when this gets committed. I suspect not because the PR won't get merged on GitHub. I'll handle it post merge if necessary.

Todo

We already have Actionlint in place. Why do we need Zizmor?

The tools are complementary. Actionlint implements 38 checks, Zizmor implements 34 in its strictest mode, but only around 9 of the checks fully overlap. Zizmor gives us a net of about 20 new checks in its default mode, including detection of archived actions, spoofable bot conditions, problematic use of GitHub Actions features and patterns, overprovisioned secrets, git ref confusion, and unpinned actions.

Actionlint primarily focuses on correctness, with some security related audits included. Zizmor primarily focues on security.

Results

Some code scanning alerts remain after I dismissed the false positives and closed some non-critical warnings.

Errors

  • ❌ use of fundamentally insecure workflow trigger
    • Refers to the pull_request_target trigger.
    • We're aware that this trigger is fundamentally risky. Need to document it inline and then close the alerts.
  • ❌ Use of "downloadArtifact" in "actions/github-script" action.
    • Need to audit these to ensure the artifact contents are not treated as trusted.
  • ❌ Use of 'actions/checkout' with a custom ref
    • Need to audit these so we're clear on where the refs originate.
  • ❌ Write to $GITHUB_ENV and $GITHUB_OUTPUT in a bash script
    • These are only dangerous if the input is user-controlled. I've closed off all the false positives, the remaining needs to be reviewed.

Warnings

  • ⚠️ Obfuscated usage of GitHub Actions features
    • Refers to incorrect usage of ${{ true }} instead of true. No security concern but needs an audit.

with:
script: |
const prNumbers = ${{ steps.linked-prs.outputs.result }};

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This combines two steps into one to avoid the need to pass the prNumbers between them.

@johnbillion johnbillion marked this pull request as ready for review October 7, 2025 13:13
@johnbillion johnbillion requested a review from desrosj October 7, 2025 13:13
@github-actions
Copy link
Copy Markdown

github-actions bot commented Oct 7, 2025

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props johnbillion.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

# Conflicts:
#	.github/workflows/phpunit-tests.yml
#	.github/workflows/reusable-cleanup-pull-requests.yml
@johnbillion
Copy link
Copy Markdown
Member Author

After having used GitHub Code Scanning on several other projects over the last year or so, I've noticed that it's a bit too easy for code scanning alerts to go unnoticed. If the default branch allows direct pushes without the commits going via a PR (or in the case of wordpress-develop, commits being mirrored in from svn) or if code scanning tools aren't included in branch protection rules then they can go unnoticed.

If you push directly to the default branch and the code fails one of the code scanning tools, you won't see code scanning results being flagged anywhere, the workflow runs won't fail, but new alerts will quietly be added to the Security -> Code Scanning Alerts screen.

Normally a GitHub project would address this with branch protection rules for PRs, but the svn mirroring means this doesn't apply. I'm tempted to switch to code scanning that causes the workflow run to fail instead of using the Code Scanning tool, but that would require a means to reliably run the workflow file linting locally and not have to depend on a GitHub Actions workflow.

@johnbillion johnbillion changed the title Add more workflow file linting with Octoscan, Zizmor, and Poutine Add more workflow file linting with Zizmor Mar 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant